昨天我們提到了 Rive 的操作空間比想像中大，以及我們跟官方許願過防抄襲功能的事，今天就稍微提一下我們自己的防抄襲方案。我是覺得這還蠻奇淫巧技的，一定不是最好的方案，但確實有發揮它的效果。

問題起源：防抄襲

我們的設計師大大做了很多非常精緻的 .riv 檔，結果有一天發現，我們被抄襲了。主要是我們的競爭對手，直接從 devtool 下載 .riv 檔，再拿去稍微改一改，就變成另一份可以用的 .riv 檔。甚至他們一次抄出了十幾份，讓我們的設計師很生氣。

Rive 跟所有靜態資源一樣，都會被下載到使用者本機裡面，由此可知，防抄襲可以從「.riv 的取得」與「.riv 的修改」這兩個方向著手：

1. .riv 的取得
   讓使用者不能從 devtool 取得 .riv，或至少不要讓他那麼好取得
2. .riv 的修改
   讓他就算取得 .riv 也不能修改

當然自從 v0.8.936 之後，Rive Editor 不再支援自行下載 .riv 編輯，所以幾乎擋掉所有抄襲 Rive 的可能性。不過在這之前，我們也想了很多方法來防抄襲，這些方法還是有參考價值，所以在這裡做個整理與紀錄，這些方法花了我們蠻多時間去做的。

先講結論

我們最後用了兩個方案防抄襲：

1. .riv 的取得
   我們把檔名加密，讓有心人難以分辨到底哪個檔名是 .riv，達到難以從 devtool 取得 .riv 的效果
2. .riv 的修改
   Rive 官方幫我們解決了，現在 Rive.Editor 不再支援自行下載 .riv 編輯修改

怎麼加密的？

類似把圖片轉成 base64 那樣，.riv 也可轉成 binary file，所以我們可以在轉換時用 key 加密，讓有心人就算找到 binary file，也會因為沒有 key 來解密，而無法取得 .riv，我們甚至有對稱加密 & 非對稱加密兩個方案。

• 第一階段：對稱加密
  前後端在線下協議一組 key，前端在線下用 key 加密 .riv 後放進 /public，後端把 key 放在 initInfo。線上要用時，前端再從 API 拿 key 解密取得 .riv 檔。
• 第二階段：非對稱加密
  前後端在線下協議 A, B 兩組 key，前端在線下用 A 加密 .riv 後放進 /public，B 放在 .env 裡面，再拿 A, B 用 XOR 計算出 key C 給後端。線上要用時，前端拿 B, C 做 XOR 回推出 A，再拿 A 解密取得 .riv 檔。

其實實務上來說，第一階段就已經非常好用了，幾乎可以擋掉 94.87% 抄襲的可能性，第二階段有點喪心病狂🥲。而且經由我們實測過後的結果，至少就我們的 .riv 檔來說，加密前後的大小都差不多，不會像圖片轉成 Base 64 有變大的問題。自從用了這招以後，就沒再看到競爭對手用我們的 .riv 檔了，設計師大大們非常開心。

好吧當然也有可能是因為 Rive Editor 不再支援自行下載 .riv 編輯修改的關係，不過這兩個機制應該都跟 Rive 本質是 JSON 有關。因為是 JSON，所以在編譯時可以加一些料進去，例如作者的 uid 或 key 之類的，才能做到 auth 的效果，所以才會說 Rive 的操作空間比想像中大。

既然可以加料，那可能可以有其他……更奇妙的應用，大家可以盡量發揮創意，多跟官方團隊許願看看🙈🙈🙈